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Foreword 



rd , 



This Technical Specification has been produced by the 3 Generation Partnership Project (3 GPP). 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 
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1 Scope 



The present stage 3 specification defines the Diameter based implementation for bootstrapping Zh interface (BSF-HSS) 
and Dz interface (BSF-SLF) for HSS resolution for the BSF, and GAA AppHcation Zn interface (BSF-NAF) in Generic 
Authentication Architecture (GAA). The definition contains procedures, message contents and coding. The procedures 
for bootstrapping and usage of bootstrapped security association are defined in 3GPP TS 33.220 [5]. 

This specification is a part of the Generic Authentication Architecture (GAA) specification series. 

The diameter based implementation is based on re-usage of Cx interface Multimedia- Auth-Request/ Answer messages 
originally between CSCF and HSS. These messages are defined in 3GPP TS 29.229 [3]. The 3GPP IMS mobility 
management uses the same definitions between CSCF and HSS. The present document defines how the defined 
messages are used with the bootstrapping and GAA application procedures (e.g. subscriber certificates) and the 
application logic that is needed in GAA network elements (BSF, HSS, and NAF). 
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Figure 1.1 depicts the relationships of these specifications to the other specifications. 
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Figure 1 .1 : Relationships to other specifications 

Figure 1.2 provides an informal overall quick introduction to the whole signalling procedures in GAA system. The 
important identifiers are marked bold and optional data items are italicised. The Ub and Ua interfaces, not defined in 
this TS , are simplified. 
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Figure 1.2: The whole signalling procedure in GAA system 
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Definitions, symbols and abbreviations 



3.1 Definitions 

For the purposes of the present document, the terms and definitions given in 3GPP TS 23.008 [10], 3GPP TR 33.919 
[4], 3GPP TS 33.220 [5] apply with following additions. 

Bootstrapping information (Bootstrapped data) in a BSE consists of a bootstrapping transaction identifier (B-TID), a key 
material (Ks), the key lifetime (expiry time), the boostrapinfo creation time, the IMPI and the GUSS (if received from HSS) 
with BSE control information. Each bootstrapping procedure creates a bootstrapped data entity with B-TID as retrieval 
key.. 

GAA application is an application that uses the security association created by GB A Bootstrapping procedure. 

GAA service is an operator specific end user service that uses the security association created by GAA Bootstrapping 
procedure. GAA services are identified by GAA Service Identifiers. A GAA service is implemented using some 
standardised or propriatary GAA application defined by GAA application type. 

NAF specific Bootstrapping information transferred from a BSE to a NAF contains NAF and its service specific parts 
from bootstrapped data and needed key information derived from the bootstrapped data. 
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Service/Application. The term service is used here in its common meaning. A service is something that a MNO offers 
to subscribers. GAA Services are identified by GAA Service Identifier (GSID). In stage 2 documents ([4], [5], [6] and 
[11]) the term appHcation is used in the same meaning i.e. MNOs offer appHcations to subscribers. There is a reason to 
avoid the usage of the term appHcation here. The application is an already reserved term in Diameter. In Diameter 
applications are identified by Application Identifiers. 

3.2 Symbols 

For the purposes of the present document, the terms and definitions given in 3GPP TS 23.008 [10]. 

3.3 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 

AK Anonymity Key 

AKA Authentication and Key Agreement 

AUTN Authentication token 

AV Authentication Vector. 3GPP AV=[RAND,AUTN,XRES,CK,IK]. 

AVP Attribute- Value-Pair in Diameter messages. 

BIA Bootstrappinglnfo- Answer message 

BIR Bootstrappinglnfo-Request message 

B S B ootS trapping Procedure 

BSF Bootstrapping server functionality 

BSF is hosted in a network element under the control of an MNO. 

B-TID Bootstrapping Transaction Identifier 

CA Certificate Authority 

CK Confidential Key 

FQDN Full QuaHfied Domain Name in URI (e.g. http://FQDN:80) 

GAA Generic Authentication Architecture 

GBA Generic Bootstrapping Architecture 

GSID GAA Service Identifier 

GUSS GBA User Security Settings 

HSS Home Subscriber System 

IK Integrity Key 

IMPI IP Multimedia Private Identity 

IMPU IP Multimedia Public Identity 

Ks Key Material 
Ks_ext_NAF MEbased key for a specific NAF 

MNO Mobile network operator 

NAF Operator-controlled network application function functionality. 

NAF is hosted in a network element under the control of an MNO. 

RAND Random challenge in authentication 

REQ In Diameter header indicates that the message is a Request. 

SCTP Stream Control Transmission Protocol 

SLF Subscription Location Function 

SSC Subscriber Certificate Procedure 

Ua UE-NAF interface for GAA applications 

Ub UE-BSF interface for bootstrapping 

UE User Equipment 
Ks_int_NAF UICC based key for a specific NAF 

USS User Security Settings (a part of GUSS) 

XRES Expected response in authentication 

Zh BSF-HSS interface for bootstrapping procedure 

Zn BSF-NAF interface for GAA applications. 
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4 GBA Bootstrapping Zh interface 

4.1 Generic bootstrapping network architecture 

The network architecture of the Bootstrapping procedure is presented in Figure 4.1. The interface Ub (bootstrapping) is 
defined in 3GPP TS 24.109 [7] and the interface Zh in this specification. 




Figure 4.1 : Network architecture of bootstrapping procedure 

The protocol stack of the Zh interface in Bootstrapping procedure is presented in Figure 4.2. The Diameter Base 
protocol is defined in [1] and the Diameter appHcation in 3GPP TS 29.229 [3]. The requirements for Zh interface are 
defined in 3GPP TS 33.220 [5]. 
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Figure 4.2: Protocol stack of Zh interface 



4.2 



Protocol Zh between BSF and HSS 



The requirements for Zh interface are defined in 3 GPP TS 33.220 [5]. 

The Bootstrapping Zh interface performs the retrieval of an authentication vector and possibly GBA User Security 
Settings from the HSS. The overall Bootstrapping procedure is depicted in Figure 4.3. The basic procedure is: 

A) A UE starts the bootstrapping procedure by protocol Ub with a BSF giving the IMPI of the user (see 3GPP TS 
24.109 [7]). 

B) The BSF starts protocol Zh with user"s HSS 

• The BSF requests user"s authentication vector and GBA User Security Settings(GUSS) corresponding to 
the IMPI. 

• The HSS supplies to the BSF the requested authentication vector and GUSS (if any). 

NOTE: If there is more than one HSS deployed within the network, the BSF may have to contact the SLF using 
the Dz interface prior to sending the request for information to the HSS (see section 6.4). 

C) The BSF continues the protocol Ub with the UE (see 3GPP TS 24.109 [7]). 
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Figure 4.3: The GBA bootstrapping procedure 



The steps of the bootstrapping procedure in Figure 4.3 are: 
Stepl 



The BSF shall send the following Bootstrapping-Request to the HSS in the format of Multimedia- Auth-Request (MAR) 
message. The content of the message is given below in the same format as in 3GPP TS 29.229 [3]. The curly brackets 
indicate mandatory AVPs. The square brackets indicate optional AVPs. The "address of" refers to the Fully Qualified 
Host Name (FQDN). 

<]yiultimedia-Auth-Request> : : =<Diameter Header: 303, REQ, PXY, 16777221 > 
< Session-Id > 

{ Vendor-Specif ic-Application-Id } 
{ Auth-Session-State } 
{ Origin-Host } 
{ Origin-Realm } 
{ Destination-Realm } 
[ Destination-Host ] 
{ User-Name } 
* [ AVP ] 

* [ Proxy- Info ] 

* [ Route-Record ] 



NO_STATE_MAINTAINED 
Address of BSF 
Realm of BSF 
Realm of HSS 
Address of the HSS 
IMPI from UE 



The content of mandatory Vendor-Specific- Application-ID according [1] is: 



<Vendor-Specif ic-Application-Id> : :=<AVP header: 
1* [Vendor- Id] 
0*1 {Auth-Application-Id} 
0*1 {Acct-Application-Id} 



260> 



3GPP is 10415 

16777221 

Omitted 
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When determining the value of Destination-Host AVP the BSF can use redirector function (SLF) to resolve the address 
of the HSS if needed (see 3GPP TS 29.229 [3]). The BSF shall set the Auth-Session-State AVP to 
NO_STATE_MAINTAINED to inform that the HSS does not need to maintain any status information for this session 
according 3GPP TS 29.229 [3]. The User-name is the IMS Private User Identity (IMPI) as required in 3GPP TS 29.228 
[2]. 

Step 2 

When the HSS receives the MAR message, the HSS shall derive the user Authentication Vector (AV) information 
according the IMPI and populates it into SIP-Auth-Data AVP as defined in 3GPP TS 29.229 [3]. If GUSS exists for the 
IMPI, the HSS shall also fetch the GUSS into the GBA-UserSecSettings AVP. 

The MAR/MAA sequence in the Zh interface must not change possible status information of the possible 
simultaneously ongoing IMS MM application sessions in the HSS. 

If the User-Name (IMPI) from the BSF is totally unknown to the HSS, the error situation 5401 is raised. 

Step 3 

The HSS shall send the following Bootstrapping- Answer message in the format of Multimedia- Auth- Answer (MAA) 
message back to the BSF. 

< ]y[ultimedia-Auth-Answer> ::= < Diameter Header: 303, PXY, 16777221 > 
< Session-Id > 
{ Vendor-Specif ic-Application-Id } 

[ Result-Code ] 

[ Experimental -Result] 

{ Auth-Session-State } ; NO_STATE_]y[AINTAINED 

{ Origin-Host } ; Address of HSS 

{ Origin-Realm } ; Realm of HSS 

[ User-Name ] ; IMPI 

*[ SIP-Auth-Data-Item ] 

[ GBA-UserSecSettings ] ; GUSS 

* [ AVP ] 

* [ Proxy- Info ] 

* [ Route-Record ] 

The HSS shall set the mandatory Auth-Session-State AVP to NO_STATE_MAINTAINED because the HSS does not 
maintain any state information about this session and the BSF does not need to send any session termination request 
3GPP TS 29.229 [3]. The User-name AVP (IMPI) may be sent back for checking. The required authentication vectors 
are sent in the SIP-Auth-Data-Items AVP. The security settings of user"s all GAA applications are sent in GBA- 
UserSecSettings AVP. 

Step 4. 

When the BSF receives the MAA message, the BSF shall check the value of the SIP- Authentication-Scheme AVP. If 
the BSF does not support the authentication-scheme the BSF shall stop processing the message and should indicate an 
error via the O&M subsystem. 

The BSF generates the needed key material (Ks) from confidential key (CK) and integrity key (IK) as described in 
3GPP TS 33.220 [5] and stores temporarily the tuple <IMPI,Ks,GBA-UserSecSettings> for further use in GAA 
applications. The rest of the bootstrapping procedure in Ub interface will later add also the Bootstrapping Transaction 
Identifier (B-TID) to that tuple as key and the key lifetime (expiry time). 
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5 GAA Application Zn interface 

5.1 Applications" network architecture 

The network architecture of the GAA applications procedure is presented in Figure 5.1. The 3 GPP GAA appHcations 
are Hsted in annex B. Different GAA applications may implement the Ua interface in different way. The Zn interface is 
defined in this specification. 




— Ua— NAF — Zn— BSF 



Figure 5.1 : Network architecture of GAA application 

The protocol stack of the Zn interface for GAA applications is presented in Figure 5.2. The diameter Base protocol is 
defined in [1] and the Diameter application in 3GPP TS 29.229 [3]. The requirements for Zn interface are defined in 3GPP 
TS 33.220 [5]. 
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Figure 5.2: Protocol stack of Zn interface 



5.2 



Protocol Zn between NAF and BSF 



The requirements for Zn interface are defined in 3 GPP TS 33.220 [5]. 

The protocol Zn retrieves the key material and possibly user security settings data by NAF from BSF. After UE is 
authenticated with the BSF, every time the UE wants to interact with an NAF the following steps are executed as 
depicted in Figure 5.3. The basic procedure is: 

A) The UE starts protocol Ua (see 3GPP TS 33.220 [5]) 

• In general, the UE and the NAF will not yet share the key(s) required to protect protocol Ua. If they already 
do, there is no need for the NAF to invoke protocol Zn. 

• It is assumed that UE supplies sufficient information to NAF, i.e. the Bootstrapping Transaction Identifier 
(B-TID), to allow the NAF to retrieve specific key material (e.g. Ks_NAF in the case of GBA_ME, and 
Ks_ext_NAF or Ks_int_NAF or both in the case of GB A_U) from BSF. 

• The UE derives the keys required to protect protocol Ua from the key material. 

B) The NAF starts protocol Zn with BSF 

• The NAF requests NAF specific key material corresponding to the information supplied by the UE to the 
NAF (i.e. the bootstrapping transaction identifier) in the start of protocol Ua. 
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• The BSF generates and supplies to the NAF the requested NAF specific key material, the expiry time , the 
bootstrapinfo creation time, and the appropriate User Security Settings defined for received application 
identifiers. 

C) The NAF continues protocol Ua with the UE (see 3GPP TS 33.221 [6]) 

Once the run of protocol Ua is completed the purpose of bootstrapping is fulfilled as it enabled UE and NAF to run 
protocol Ua in a secure way. 



The common GAA application procedure is presented in Figure 5.3. 



UE 



Ua 



NAF 



Ziv 



BSF 



UE knows: 
< B-TID. Ks> 



{ a security association 
created by bootstrapping } 



BSF has tuple: 
< B-TID. /MP/.Ks. 
ME-Ks, UICC-Ks,GUSS> 



UE start the GAA application procedure 
by sending a B-TID. 



GUSS is 

GBA User Security Settings. 

GSID is 

GAA Service Indentifier. 



1- Bootstrapping-lnfo-Request 
( B-TID, GSID*, NAF-ld) 



2. BSF checks the B-TID 

and derives 
ME-Key and UlCC-Key 



UE and NAF mutually authenticate 
each others using ME-Ks 



3. Bootstrapping-lnfo-Answer 

( IMPI, Key-ExpiryTime, 

Ks_(ext)_NAF, Ks_/>7LA//\F, 

BootstraplnfoCreationTime, 

UserSecSetting* ) 



Figure 5.3: The GAA application procedure 

The steps of the GAA appHcation procedure in Figure 5.3 are: 



Stepl 



The NAF shall send a Bootstrapping-lnfo-Request message (BIR) to the BSF. The content of the message is 
given here in the same format as in 3GPP TS 29.229 [3]. The curly brackets indicate mandatory AVPs. The 
square brackets indicate optional AVP. The address refers to the Fully Qualified Host Name (FQDN). 
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< Bootstrapping-Info-Request> ::=<Diameter Header: 310, REQ, PXY, 16777220 > 



< Session-Id > 

{ Vendor-Specif ic-Application-Id } 

{ Origin-Host } 

{ Origin-Realm } 

{ Destination-Realm } 

[ Destination-Host ] 

* [ GAA-Service-Identif ier ] 

{ Transaction-Identifier } 

{ NAF-Id } 

[ GBA_U-Awareness- Indicator ] 

* [ AVP ] 

* [ Proxy- Info ] 

* [ Route-Record ] 



Address of NAF 

Realm of NAF 

Realm of BSF 

Address of the BSF 

Service identifiers 

B-TID 

NAF_ID 

GBA U awareness of the NAF 



The content of Vendor-Specific- Application-ID according [1] is: 

<Vendor-Specif ic-Application-Id> : : =<AVP header: 260> 
1* [Vendor- Id] 
0*1 {Auth- Application- Id} 
0*1 {Acct-Application-Id} 



3GPP is 10415 

16777220 

Omitted 



The Destination-Realm AVP is set to subscriber"s BSF. The address of the BSF is extracted from the B-TID. 

NOTE: In the case where the subscriber has contacted a NAF that is in a visited network, the NAF contacts the 
subscriber's home BSF through a Diameter-Proxy (D-Proxy) that is located in the same network as the 
NAF. The local BSF and the D-Proxy may be co-located. See 3GPP TS 33.220 [6]. 

The NAF indicates the GAA services for which the information is retrieved by GAA-Service-Identif ier AVPs. 
The Bootstrapping Transaction Identifier defines the earlier bootstrapping procedure execution. 



Step 2 



In the successful case the BSF has a tuple < B-TID JMPI,Ks, Key lifetime, Bootstrapinfo creation time, GBA- 
UserSecSettings> identified by Bootstrapping Transaction Identifier (B-TID). When the BSF receives the 
request it checks the existence and validity of the tuple for given B-TID. If checking fails the BSF sends an 
Answer message with Experimental-Result set to indicate the error type 5403. If the tuple for B-TID exists, but 
is expired, error type 5403 is also send to indicate needs for renewal of the boostrapping procedure. In successful 
case the Result-Code is set to 2xxx as defined in [1]. 

The BSF derives the key material for the ME (i.e., Ks_NAF in the case of GB A_ME, and Ks_ext_NAF in the 
case of GBA_U) and possibly the key material for the UICC (i.e., Ks_int_NAF in the case of GBA_U) 
according to the B-TID and packs them into ME-Key-Material AVP and possible UICC-Key-Material AVP. The 
ME-Key-Material contains Ks_(ext)_NAF and the UICC -key-Material contains the Ks_int_NAF key. The BSF 
select correct user"s Security Settings according the request" s GAA- Service-Identifier AVP to GBA- 
UserSecSettings AVP. If NAF grouping is used by the operator and there are one or more USSs corresponding to 
the requested GSID, then also the nafGroup attribute of USS is checked. If the NAF has sent a GAA-Service- 
Identifier that does not have corresponding user"s security settings, and the BSF is locally configured to reject 
those requests from the NAF, then the error 5402 is raised. If the NAF has sent a GAA-Service-Identifierthat 
have corresponding user's security settings, but the BSF is locally configured to reject those from that NAF, then 
the error 5402 is raised too. 

The NAF may be addressed from the UE with different FQDNs. The BSF shall check if this NAF-Id is allowed 
to be used for the NAF. If the NAF identified by its Origin-Host AVP is configured in the BSF not to be 
authorized to use the given NAF-Id, the BSF may raise the error situation 5402. The BSF may also be configured 
so that a certain NAF is not authorized to use a certain GAA-Service-Identifier. This situation may be also 
indicated by error code 5402. 



Step 3 



After that the BSF shall send a Bootstrapping-Info- Answer message (BIA) back to the NAF. 
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< Boostrapping-Info-Answer> ::= < Diameter Header: 310, PXY, 16777220 > 
< Session-Id > 
{ Vendor-Specif ic-Application-Id } 

[ Result-Code ] 

[ Experimental-Result] 
{ Origin-Host } 
{ Origin-Realm } 

[ User-Name ] 

[ ME-Key-Material ] 

[ UICC-Key-Material ] 

[ Key-ExpiryTime ] 

[ BootstrapInfoCreationTime ] 

[ GBA-UserSecSettings ] 

[ GBA- Type ] 

* [ AVP ] 

* [ Proxy- Info ] 

* [ Route-Record ] 

The BSF may or may not send the User-name AVP (IMPI) according its configuration. 

The mandatory common key material with the ME (Ks_NAF or Ks_ext_NAF) is sent in the ME-Key-Material 
AVP. The common key material with the UICC (Ks_int_NAF) is optionally sent in the UICC-Key-Material 
AVP only if the "uiccType" tag in bsflnfo from the HSS is set to "GBA_U". 

The Key-ExpiryTime AVP contains the expiry time of the Bootstrapping information in the BSF according its 
configuration. The expiry time is represented according the Diameter Time data format in seconds that have 
passed since Oh on January 1, 1900 UTC . If a special key lifetime value is given in the "lifeTime" tag inside the 
bsflnfo from the HSS in bootstraping procedure, it is used instead of the BSF default configuration value when 
the expiry time is calculated. 

The BootstrapInfoCreationTime AVP contains the bootstrapinfo creation time, i.e., creation time of the 
Bootstrapping information in the BSF. The bootstrapinfo creation time is represented in seconds that have passed 
since January 1, 1900 00:00:00.000 UTC. 

The BSF selects the appropriate User Security Settings (if any) to the GBA-UserSecSettings AVP from stored 
GAA-UserSecSettings in Bootstrapping information according the GBA-Service-Identifier AVPs in the request 
message. 

The BSF shall indicate the type of used authentication in the bootstrapping procedure to the NAF in GBA-Type, 
if other than 3G GBA type has been performed. 

When the NAF receives the BIA message, the NAF shall check the value of the GBA-Type AVP if it is included in the 
message. If the NAF does not support the GBA-Type the NAF shall stop processing the message and should indicate an 
error via the O&M subsystem. The further procedure in the NAF when the BIA is received is described in 3GPP TS 
33.220 [5], 3GPP TS 33.222 [11] and optionally in GAA service type specific TSs. 



6 Diameter application for Zh and Zn interfaces 

6.1 Command-Code values 

The Zn interface assigns new Command-Code 310. 

The messages in Zh interface use the same Command-Code value 303 as Multimedia- Auth-Request/ Answer messages 
defined in 3GPP TS 29.229 [3] for Cx interface. 

6.2 Result-Code AVP values 

This section defines new result code values that must be supported by all Diameter implementations that conform to this 
specification. When one of the result codes defined here is included in a response, it shall be inside an Experimental- 
Result AVP and Result-Code AVP shall be absent. 
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6.2.1 Success 

Errors that fall within the Success category are used to inform a peer that a request has been successfully completed. 

The success category result codes defined in 3GPP TS 29.229 [3] for Cx interface are useless and therefore not required 
in Zh and Zn interfaces. 

6.2.2 Permanent failures 

Errors that fall within the Permanent Failures category are used to inform the peer that the request failed, and should not 
be attempted again. 

The Permanent failure category result codes defined in 3GPP TS 29.229 [3] for Cx interface are useless and therefore 
not required in Zh and Zn interfaces. 

6.2.2.1 DIAMETER_ERRORJMPI_UNKNOWN (5401) 

A message was received by the HSS for an IMPI that is unknown. 

6.2.2.2 DIAMETER_ERROR_NOT_AUTHORIZED (5402) 

A message was received by the BSF which the BSF can not authorize. In this case the NAF should indicate to the UE 
that the service is not allowed. 



6.2.2.3 



DIAMETER_ERROR_TRANSACTIONJDENTIFIERJNVALID(5403) 



A message was received by the BSF for an invalid (e.g. unknown or expired) Bootstrapping Transaction Identifier (B- 
TID). In this case the NAF should request the UE to bootstrap again. 



6.2.2.4 



Void 



6.2.2.5 



Void 



6.2.2.6 



Void 



6.2.2.7 



Void 



6.3 



AVPs 



The AVPs defined in 3GPP TS 29.229 [3] for 3GPP IMS Cx interface Multimedia-Auth-Request/Answer messages are 
used as they are. 

The following table describes the additional new Diameter AVPs defined for the Zh and Zn interface protocol, their 
AVP Code values, types, possible flag values and whether or not the AVP may be encrypted. The Vendor-Id header of 
all AVPs defined in this specification shall be set to 3GPP (10415). 

Table 6.1 : New Diameter Multimedia Application AVPs 











AVP Flag rules 




Attribute Name 


AVP 

Code 


Section 
defined 


Value Type 


Must 


May 


Should 
not 


Must 
not 


May 
Encr. 


GBA-UserSecSettings 


400 


6.3.1.1 


OctedString 


M,V 








No 


Transaction-Identifier 


401 


6.3.1.2 


OctetString 


M,V 








No 


NAF-Id 


402 


6.3.1.3 


OctetString 


M,V 








No 
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GAA-Service-Identifier 


403 


6.3.1.4 


OctedString 


M,V 








No 


Key-ExpiryTime 


404 


6.3.1.5 


Time 


M,V 








No 


ME-Key-Material 


405 


6.3.1.6 


OctedString 


M,V 








No 


UICC-Key-Material 


406 


6.3.1.7 


OctedString 


M,V 








No 


GBA_U- Awareness-Indicator 


407 


6.3.1.8 


Enumerated 


M,V 








No 


B ootstrapinf oCreationTime 


408 


6.3.1.9 


Time 


M,V 








No 


GBA-Type 


410 


6.3.1.10 


Enumerated 


M,V 








No 


NOTE 1 : The AVP header bit denoted as "M", indicates whether support of the AVP is required. The AVP header 
bit denoted as "V", indicates whether the optional Vendor-ID field is present in the AVP header. 



6.3.1 Common AVPs 



6.3.1.1 



GBA-UserSecSettings AVP 



The GAA-UserSecSettings AVP (AVP code 400) is of type OctetString. If transmitted on the Zh interface it contains 
GBA user security settings (GUSS). If transmitted on the the Zh interface it contains the relevant USSs only. The 
content of GBA-UserSec Settings AVP is a XML document whose root element shall be the "guss" element for the Zh 
interface and the "ussList" element for the Zn interface. The XML schemas is defined in annex A. 



6.3.1.2 



Transaction-Identifier AVP 



The Transaction-Identifier AVP (AVP code 401) is of type OctetString. This AVP contains the Bootstrapping 
Transcation Identifier (B-TID). 



6.3.1.3 



NAF-ld 



The NAF-Id AVP (AVP code 402) is of type OctetString. This AVP contains the full quahfied domain name (FQDN) 
of the NAF that the UE uses concatenated with the Ua security protocol indentifier as specified in TS33.220 [5]. The 
FQDN of the NAF that is part of the NAF_Id may be a different domain name that with which the BSE knows the NAF. 



6.3.1.4 



GAA-Service-Identifier AVP 



The GAA-Service-identifier AVP (AVP code 403) is of type OctedString. This AVP informs a BSE about the support 
of a GAA-service by the NAF. According this AVP the BSE can select the right service" s user security settings. 

For 3GPP standardized services (e.g., PKI portal), the GAA-Service-Identifier (GSID) shall be in the range to 999999, 
and the currently standardized values for GSID shall be the GAA- Application-Type-Code of the particular service. The 
GAA Service Type Codes for 3GPP standardized services are defined in Annex B. 

NOTE: In the future, standardized GSID values that are different than the GAA Service Type Code may be 
standardised (e.g. to differentiate between the services "MBMS streaming" and "MBMS download"). 



Examples: 



The GSID is "1" for all PKI-portals, and "4" for all MBMS services. 



6.3.1.5 



Key-ExpiryTime AVP 



The Key-ExpiryTime AVP (AVP code 404) is of type Time. This AVP informs the NAF about the expiry time of the 
key. 



6.3.1.6 



ME-Key-Material AVP 



The required ME-Key-Material AVP (AVP code 405) is of type OctetString. The NAF is sharing this key material 
(Ks_NAF in the case of GBA_ME or Ks_ext_NAF in the case of GBA_U) with the Mobile Equipment (ME). 
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6.3.1 .7 UlCC-Key-Material AVP 

The condition UICC-Key-Material AVP (AVP code 406) is of type OctetString. The NAF may share this key material 
(Ks_int_NAF in the case of GBA_U) with a security element (e.g. USIM, ISIM, etc..) in the UICC. Only some GAA 
applications use this conditional AVP. 

6.3.1 .8 GBA_U-Awareness-lndicator 

The conditional GB A_U-Awareness-Indicator AVP (AVP code 407) is of type Enumerated. The following values are 
defined. 

NO (0) The sending node is not GBA_U aware 

YES(l) The sending node is GBA_U aware 

The default value is i.e. absence of this AVP indicates that the sending node is not GB A_U aware. 

6.3.1 .9 BootstraplnfoCreationTime AVP 

The BootstraplnfoCreationTime AVP (AVP code 408) is of type Time. This AVP informs the NAF about the 
bootstrapinfo cration time of the key. 

6.3.1.10 GBA-Type 

The GBA-Type AVP (AVP code 410) is of type Enumerated. The AVP informs the NAF about the authentication type 
that was used during bootstrapping procedure. 

The following value is defined: 

• 3G GBA (0) The 3G GBA has been performed as defined in TS 33.220 [5]. 

The default value is i.e. the absence of this AVP indicates 3G GBA 



6.4 User identity to HSS resolution 



The User identity to HSS resolution mechanism enables the BSE to find the address of the HSS that holds the subscriber 
data for a given subscriber when multiple and separately addressable HSSs have been deployed by the network 
operator. The resolution mechanism is not required in networks that utilise a single HSS or when an BSE is configured 
to use pre-defined HSS. 

The resolution mechanism is based on the Subscription Locator Function (SLE) and is equivalent to that described for 
the Cx/Dx interface described in 3GPP TS 23.228 [12]. The BSE accesses the subscription locator via the Dz interface. 
The Dz interface is always used in conjunction with the Zh interface. The Dz interface is based on Diameter. Its 
functionality is implemented by means of the routing mechanism provided by an enhanced Diameter redirect agent, 
which is able to extract the Subscriber identity from the received requests. 

To get the HSS address the BSE sends to the SLE the Zh requests aimed for the HSS. On receipt of the HSS address 
from the SLE, the BSE shall send the Zh requests to the HSS. The BSE may store the HSS address and use it in further 
requests associated to the same Subscriber. 

In networks where the use of the user identity to HSS resolution mechanism is required and the BSE is not configured to 
use predefined HSS, each BSE shall be configured with the address/name of the SLE implementing this resolution 
mechanism. 
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Use of namespaces 



This clause contains the namespaces that have either been created in this 3GPP specification, or in 3GPP specification 
3 GPP TS 29.229 [3] or the values assigned to existing namespaces managed by I AN A. 

7.1 AVP codes 

This specification reserves the 3GPP vendor specific values 10415:400-499 and assigns values 10415:400-408, and 410 
for the GAA from the 3 GPP AVP Code namespace for 3 GPP Diameter applications ([8]). The 3 GPP vendor specific 
AVP code space is managed by 3GPP CT4. See section 6 for the assignment of the namespace in this specification. 

Besides the Diameter Base Protocol AVPs [1] this specification reuses the following AVPs from 3GPP TS 29.229 [3]: 

Authentication-Session-State, User-Name, SIP-Auth-Data-Item and SIP-Number-Auth- 
Items. 

7.2 Experimental-Result-Code AVP values 

This specification reserves Experimental-Result-Code AVP values 10415:2401-2409 and 10415:5401-5409. See section 
6.2. 

7.3 Command Code values 

Only Command-Codes 310 and 303 from 3GPP TS 29.229 [3] is used in this specification. 

This specification reuses only the Command-Code value, not the content of the original specification. The AVPs, that are 
defined required in TS 29.229 [3], but are not needed in Zh or Zn interfaces, are removed and are therefore not required in 
Zh or Zn interface messages. All new AVPs for GAA are defined optional although they may be mandatory in GAA 
viewpoint. 

This specification does not assign new command codes to the 3GPP TS 29.229 [3]. 
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Annex A (normative): 
GBA-UserSecSettings XML definition 

This annex contains the XML schema definition for an XML document carrying the GBA User Security Settings inside 
GBA-UserSecSettings AVP in Zh and Zn interface. 

<?xml version="l . 0" encoding="UTF-8 " ?> 

<xs : schema targe tNamespace= " urn : 3gpp : gba : GBAGUSSSchema- R6 : 2 8 - 1 " 
xmlns : tns= " urn : 3gpp : gba : GBAGUSSSchema- R6 : 2 8 - 1 " 
xmlns :xs="http: //www.w3 . org/200l/XMLSchema" 
elementFormDefault=" qualified" 
attributeFormDefault= "unqualified" > 

<!-- This import brings in the XML language attribute xml:lang--> 
<xs : import namespace="http : //www. w3 . org/XML/l998/namespace" 
schemaLocation="http : //www. w3 . org/2 OOl/xml .xsd"/> 

<!-- Root element to be used in Zh reference point- -> 
<xs: element name="guss" type=" tns :gussType"/> 

<!-- Root element to be used in Zn reference point- -> 
<xs: element name="ussList " type=" tns :ussListType"/> 

<xs : complexType name="ExtensionType" > 

<xs : sequence> 

<xs : any processContents="lax" minOccurs=" " maxOccurs= "unbounded" /> 

</xs : sequence> 
</xs : complexType > 

<!-- The whole user"s GBA specific data set --> 
<xs : complexType name="gussType" > 
<xs : sequence> 

<xs: element name="bsf Inf o" type=" tns :bsf Inf oType" minOccurs=" "/> 
<xs: element name="ussList " type=" tns :ussListType"/> 

<xs:element name= "Extension" type=" tns : ExtensionType" minOccurs=" "/> 
<xs:any namespace="##other" processContents="lax" minOccurs=" " 
maxOccur s = " unbounded " / > 
</xs : sequence> 

<xs : attribute name="id" type="xs : string" /> 
</xs : complexType > 

<!-- BSF specific information element --> 
<xs : complexType name="bsf Inf oType" > 
<xs : sequence> 

<xs: element name="uiccType" type="xs : string" minOccurs=" " /> 
<xs:element name="lif eTime" type="xs : integer" minOccurs=" " /> 

<xs: element name=" Extension" type=" tns : ExtensionType" minOccurs=" "/> 
<xs : any namespace="##other" processContents="lax" minOccurs=" " 
maxOccur s = " unbounded " / > 
</xs : sequence> 
</xs : complexType > 

<!--List of all users individual User Security Settings --> 
<xs : complexType name="ussListType" > 

<xs : sequence minOccurs=" " maxOccurs= "unbounded" > 
<xs: element name="uss" type=" tns :ussType"/> 

<xs: element name= "Extension" type=" tns : ExtensionType" minOccurs=" "/> 
<xs : any namespace="##other" processContents="lax" minOccurs=" " 
maxOccur s = " unbounded " / > 
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</xs : sequence> 
</xs : complexType> 

<!-- User Security Setting data --> 

<xs : complexType name="ussType" > 
<xs : sequence> 

<xs: element name="uids" type=" tns :uidsType"/> 
<xs: element name=" flags" type=" tns : f lagsType"/> 

<xs: element name=" Extension" type=" tns : ExtensionType" minOccurs=" "/> 
<xs : any namespace="##other" processContents="lax" minOccurs=" " 
maxOccur s = " unbounded " / > 
</xs : sequence> 

<xs : attribute name="id" use= "required" type="xs : string" /> 
<xs : attribute name="type" use=" required" type="xs : int "/> 
<xs : attribute name="naf Group" use= "optional" type="xs : string" /> 
</xs : complexType > 

<!-- User Public Identities for authentication --> 
<xs : complexType name="uidsType" > 

<xs : sequence minOccurs=" 1" maxOccurs= "unbounded" > 
<xs: element name="uid" type="xs : string" /> 

<xs: element name=" Extension" type=" tns : ExtensionType" minOccurs=" "/> 
<xs:any namespace="##other" processContents="lax" minOccurs=" " 
maxOccur s = " unbounded " / > 
</xs : sequence> 
</xs : complexType > 

<!-- GAA Application type specific Authorization flag codes --> 
<xs : complexType name= " f lagsType " > 

<xs : sequence minOccurs=" " maxOccurs= "unbounded" > 
<xs: element name="flag" type="xs : int "/> 

<xs: element name=" Extension" type=" tns : ExtensionType" minOccurs=" "/> 
<xs:any namespace="##other" processContents="lax" minOccurs=" " 
maxOccur s = " unbounded " / > 
</xs : sequence> 
</xs : complexType > 

</xs : schema> 

Note: The <xs:any> element within the complex type ExtensionType allows for compatible standard extensions in 
future releases. The <xs:any> elements within the other complex types allow for compatible private 
extensions. 



The values are: 



The value of the attribute "id" in the element "guss" is the the same as user"s IM Private Identity (IMPI) 
used in User-Name AVP. 

The value of the attribute "id" in the element "uss" is the same as service identifier (GSID) used in GAA- 
Service-Identifier AVP. 

The value of the element "uiccType" in the element "bsflnfo" is: 

GBA to indicate the basic case, or 

GBA_U to indicate that generation of Ks_int_NAF is also required in the BSF. 

The default value is GBA. 

The value of the element "lifeTime" in the element "bsflnfo" indicates a user specific key lifetime (duration 
in seconds). If the lifeTime element is missing the default value in the BSF is used. 

The value of attribute "type" in the element "uss" is GAA service type code defined in annex B. 
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• The value of attribute "naf Group" in the element "uss" is an operator internal group designator for a NAF 
group the USS is valid for. If this attribute is missing then only the attribute "id" is used for selection of this 
element. 

• Values of the element "uid" are user"s public authentication identities from the HSS. 

• Values of element "flag" are user"s authorization flag codes from the HSS for GAA service type indicated 
in the type attribute in the parent uss element. If an authorization flag exist the NAF have permission to 
give the corresponding service, otherwise not 

In the following illustrative example the values are italised and underlined. The content of one User Security Setting 
tag is boxed. 

<guss id= " 35850000483 6551@ims . mncOBO . mcc358 . 3Qppnetwork . otq '' > 
<bsf Inf o> 

<lifeTime>864 0</lifeTime> 
</bsf Info 
<ussList> 



<uss id="l" type="l" nafGroup="A" > 
<uids> 

<uid> tel :358504836551 </\i±d> 
<uid> lauri . laitinen@example . com < /uid> 

</uids> 
<f lags> 

<fl3ig>X</flag> 

</f lags> 
</uss> 



</ussList> 
</guss> 



The above GAA User Security Settings example for user "358500004836551 @ ims.mnc050.mcc358.3gppnetwork.org" 
defines that for PKI-Portal (GAA service type code is 1) services are allowed for user identities "tel:35850483655r' 
and "lauri.laitinen@example.com" and authentication is allowed (flag 1 exists) but non-repudiation is not allowed (flag 
2 is missing) to NAFs that provide the GAA service identified by "1" GAA Service Identifier. This particular USS for 
PKI-Portal is intended to be used only with a NAF group that is labeled as "A" (NAF groupings and NAFs that belong 
to these groups are specified by the MNO). The BSF shall not generate UICC-Ks, because uiccType is missing. A 
special key lifetime defines that athe duration after which the key expires is 86400 seconds. 



<! [CDATA[ 


<?xml version= ' 1 . ' ?> 








<ussList> 










<uss 


id="l" type="l"> 
<uids> 

<uid>tel :358504836551</u±d> 










<u±d>lauri . laitinen@example . 


com< 


/ui 


d> 




</uids> 










<f lags> 










< f 1 ag > 1 </f 1 agr> 










</f lags> 








</uss> 








</ussList 


> 








]]> 











The above is an example how the value of "GAA-UserSecSettings" in Diameter based Zn reference point is populated. 

NOTE: The BSF has removed the "nafGroup" attribute from "uss" element. Also, the XML document has been 
surrounded by "<![CDATA[" and "]]>" tags, so that the XML parser handling the outer message (i.e., in 
Web Services case) will not parse the ussList. The ussList will be parsed by the application itself handling 
the incoming message. 
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Annex B (normative): GAA Service Type Codes 

The GAA Service Type Code values are used in GAA to indicate interpretation, coding and usage of GAA service type 
specific data. 

For examples each GAA service type may have their own set of authorization flags. Meaning and coding of these flags 
are defined in Annex C. There may also be proprietary GAA service types with their own definitions in the future. 

Code values - 999999 are reserved for standardized GAA service types. 

The following values are defined for standardized GAA service types with 3GPP specification: 

Unspecific service 

1 PKI-Portal 

2 Authentication Proxy 

3 Presence 

4 MBMS 

Default value is 0. An unspecific service may or may not have user security settings containing or not a list of public 
identities. An unspecific service cannot have specified authorization flags or other service type specific data. 
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Annex C (normative): GAA Authorization flag codes 

For GAA services which have a defined set of special authorization flag codes the following rule holds: The service 
specified by the GAA authorization flag codes is allowed for a user only if user"s user security setting contains that 
flag. 

The following standardised GAA service types that are listed in previous annex B have the following special 
authorization flag codes: 

PKI-Portal (1) 

1 Authentication allowed 

2 Non-repudiation allowed 



ETSI 



3GPP TS 29.109 version 6.9.0 Release 6 



26 



ETSI TS 129 109 V6.9.0 (2008-04) 



Annex D (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


R 
e 

V 


Subject/Comment 


Old 


New 


2004-09 


CN#25 


NP-040410 






Version 2.0.0 approved in CN#25 


2.0.0 


6.0.0 


2004-12 
2004-12 
2004-12 
2004-12 
2004-12 
2004-12 
2004-12 


CN#26 


NP-040580 


001 




Authorization Flag Code Annex 


6.0.0 


6.1.0 


002 




Finalization of GAA Service Identifier 


003 


1 


BSF control information (bsflnfo) tag to GUSS 


005 




Structure to GAA Service Indentifier 


006 


1 


Finalisation of terminology 


008 


1 


Command code 310 Zn messages 


009 




Introduction of NAF groups 


2005-01 










Fix Word problem 


6.1.0 


6.1.1 


2005-03 


CN#27 


NP-050041 


010 




GAA Error Codes 


6.1.1 


6.2.0 


Oil 




Only one AV from HSS to BSF 


012 




Clarification of LifeTime/ExpiryTime terminology 


013 


1 


Application identifiers to Z-interfaces 


014 


1 


Modification of key lifetime material 


2005-06 


CT#28 


CP-050090 


0015 




XML extensibility 


6.2.0 


6.3.0 


0016 


1 


Remove BSF from visited network 


2005-09 


CT#29 


CP-050300 


0017 


1 


Correction for GBA with multiple HSS"s 


6.3.0 


6.4.0 


0021 




Key naming alignment with TS 33.220 


2005-12 


CT#30 


CP-050613 
CP-050609 


0018 


3 


XML syntax correction 


6.4.0 


6.5.0 


0023 




Authentication error handling in Zh and Zn 


2006-03 


CT#31 


CP-060071 


0024 


1 


Correction of NAF ID 


6.5.0 


6.6.0 


2007-06 


CT#36 


CP-070317 


0039 


1 


GUSS schema fix 


6.6.0 


6.7.0 


2007-12 


CT#38 


CP-070741 


0044 


1 


GUSS and USS handling corrections 


6.7.0 


6.8.0 


2008-03 


CT#39 


CP-080013 


0045 




GBA-UserSecSettings XML fix 


6.8.0 


6.9.0 



ETSI 



3GPP TS 29.109 version 6.9.0 Release 6 



27 



ETSI TS 129 109 V6.9.0 (2008-04) 



History 


Document history 


V6.1.1 


January 2005 


PubHcation 


V6.2.0 


March 2005 


PubHcation 


V6.3.0 


June 2005 


PubHcation 


V6.4.0 


September 2005 


PubHcation 


V6.5.0 


December 2005 


PubHcation 


V6.6.0 


March 2006 


PubHcation 


V6.7.0 


June 2007 


PubHcation 


V6.8.0 


January 2008 


PubHcation 


V6.9.0 


April 2008 


PubHcation 



ETSI 



